implement resources API part 2 by aalves08 · Pull Request #17749 · rancher/dashboard

aalves08 · 2026-05-20T13:59:44Z

Summary

Implements Resources API Part 2: create, update, patch, and delete operations at both the ResourcesApi level (resources.cluster.* / resources.mgmt.*) and the ResourceInstanceApi level (resourceInstance.*).

NOTE: demo interaction with persistentvolume list view to test (to be deleted in the end)

Occurred changes and/or fixed issues

New write operations added to the Resources API:

Method	Level	RBAC	HTTP	Cache
`resources.cluster.create(data)`	ResourcesApi	`canCreate`	POST	Updates store
`resources.cluster.patch(type, id, data)`	ResourcesApi	None	PATCH (merge-patch)	No cache update
`resources.cluster.update(type, id, data)`	ResourcesApi	None	PUT (cleanForSave)	No cache update
`resources.cluster.delete(type, id)`	ResourcesApi	None	DELETE	No cache update
`resourceInstance.patch(data)`	ResourceInstanceApi	`canEdit`	PATCH (merge-patch)	Merges response into store
`resourceInstance.update()`	ResourceInstanceApi	`canEdit`	PUT (via model.save)	Updates store
`resourceInstance.delete()`	ResourceInstanceApi	`canDelete`	DELETE (via model.remove)	Updates store

All methods are available on both cluster and mgmt scopes (ClusterApi and MgmtApi are type aliases to ResourcesApi).

Existing read operations (find, findAll, findFiltered) now wrap results in ResourceInstanceImpl, so every resource returned by the API has patch(), update(), and delete() available out of the box.

Technical notes summary

ResourceInstanceImpl wrapping: All resources returned from the API (find, findAll, findFiltered, create) are now wrapped in ResourceInstanceImpl. This provides the instance-level methods (patch, update, delete) on every returned resource.
_model is non-enumerable: The underlying store model reference is stored via Object.defineProperty with enumerable: false. This prevents structuredClone and JSON.stringify from attempting to serialize store internals (functions, dispatch refs, circular references), which is critical for Vue 3 reactive compatibility.
declare keyword for _model: Uses declare _model: any instead of a class field initializer to avoid TypeScript emitting a runtime assignment that would override the non-enumerable Object.defineProperty set in the constructor.
invalidatePageCache: false: The resourceInstance.patch() method explicitly passes invalidatePageCache: false when dispatching load after a successful patch. Without this, the store mutation defaults invalidatePageCache to true, which clears paginated list data and causes resources to disappear from list views.
toJSON fallback: ResourceInstanceImpl.toJSON() defensively checks for _model.toJSON before calling it, falling back to a shallow spread. This prevents errors when the model lacks a toJSON method (e.g. in test mocks).
resourceUrl helper: A new private method on ResourcesApiClassImpl builds resource URLs from schema.linkFor('collection') + '/' + resourceId. It reuses the existing isNamespaced() validation to enforce namespace/name format for namespaced resources.
CreateResourceData type: New type exported from the barrel — { type: ResourceType } & Record<string, any> — enforces the mandatory type property on create data.
delete() added alongside remove(): remove() is kept for backward compatibility. delete() is the new public method that adds RBAC checking before delegating to model.remove().

Areas or cases that should be tested

Create: Verify resources.cluster.create() with valid data, verify permission denial when canCreate is false
Patch (ResourcesApi): Verify resources.cluster.patch() sends only partial data with application/merge-patch+json content type, verify namespace validation
Patch (ResourceInstanceApi): Verify resourceInstance.patch() checks canEdit, sends partial data, merges response back into the instance, and does not invalidate paginated list views
Update (ResourcesApi): Verify resources.cluster.update() runs cleanForSave and sends full data with PUT
Update (ResourceInstanceApi): Verify resourceInstance.update() checks canEdit and delegates to model.save()
Delete (ResourcesApi): Verify resources.cluster.delete() sends DELETE request with correct URL
Delete (ResourceInstanceApi): Verify resourceInstance.delete() checks canDelete and delegates to model.remove()
All methods on mgmt scope: Verify the same operations work on resources.mgmt.*
Namespaced vs cluster-scoped resources: Verify correct URL construction and namespace validation for both types
Tested locally with Chrome

Areas which could experience regressions

List views using pagination (findFiltered / findPage): The ResourceInstanceImpl wrapping in findFiltered now maps over both array results and transient .data arrays. Verify paginated lists still render correctly.
find / findAll consumers: Any code that uses toStrictEqual or instanceof checks against raw store models will see ResourceInstanceImpl instances instead. Property access is unchanged since getters proxy through to the model.
Extensions using ResourceInstanceApi: The interface now exposes patch(), update(), and delete() — no breaking changes, but extensions get new methods in IntelliSense.
Vue reactivity with resource instances stored in component data: The _model non-enumerable change should be transparent, but verify that resource data remains reactive when stored in Vue component state.

Screenshot/Video

N/A — API-only changes with no UI modifications.

Checklist

The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
The PR has a Milestone
The PR template has been filled out
The PR has been self reviewed
The PR has a reviewer assigned
The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes
The PR has been reviewed in terms of Accessibility
The PR has considered, and if applicable tested with, the three Global Roles Admin, Standard User and User Base

…ersistentvolume list view (to be deleted)

richard-cox

There's lots of compile / transpile time TS warnings

WARNING  Compiled with 13 warnings                                                                                                                                                                         

warning  in ./shell/apis/intf/resources.ts

export 'ResourceType' (reexported as 'ResourceType') was not found in '@shell/apis/intf/resources-api/resource-base' (module has no exports)

richard-cox · 2026-05-27T12:12:43Z

 | :--- | :--- |
 | [Cluster API](./resources-api/interfaces/ClusterApi) | Interact with cluster-scoped Kubernetes resources (Pods, Deployments, Services, etc.) |
 | [Management API](./resources-api/interfaces/MgmtApi) | Interact with global Rancher resources (Users, Clusters, Settings, etc.) |
+| [Resource Instance API](./resources-api/interfaces/ResourceInstanceApi) | Interact any given Kubernetes resource instance |


i don't think we need to surface this as a major api, it's more a facet of the above two

richard-cox · 2026-05-27T12:21:20Z

  sort:     ['provisioner'],
 };

+export const PERSISTENT_VOLUME_CAPACITY = {


just in case, remember to remove this with the other persistentvolume changes

richard-cox · 2026-05-27T12:25:13Z

+ * @interface
+ * Data object for creating a new resource. Must include a `type` property.
+ *
+ * @example


probably worth creating an instance of CreateResourceData first and then using it for it's indented purpose. this makes it nice and clear

richard-cox · 2026-05-27T12:32:33Z

+ * });
+ * ```
+ */
+export type CreateResourceData = { type: ResourceType } & Record<string, any>;


this might be more of a preference thing, but why not just... ?

export type CreateResourceData = { [key: string]: any, type: ResourceType, };

richard-cox · 2026-05-27T13:53:46Z

+      await model.save();
+
+      return new ResourceInstanceImpl(model) as T;
+    } catch (e: unknown) {


i was playing around with the API and got this consoe.error

Resource API error - cluster - Failed to create resource of type "pod": undefined

no stack trace or anything to go on

this took me down a long path of trying to work out how to resolve

the Error thrown wasn't an error, but an array of strings (this shouldn't happen, but is)

the console.error didn't print this because an array has not e.message

i'd try/catch'd the line that threw the error so i didn't get anything on console regarding the error that was actually an array

i think to help with this we just need to update surfaceError

private surfaceError(message: string, e?: any): never { console.error(`Resource API error - ${ this.storeType } - ${ message }`, e); // eslint-disable-line no-console throw new Error(`Resource API error - ${ this.storeType } - ${ message }`, { cause: e }); }

richard-cox · 2026-05-27T13:58:34Z

+      await model.save();
+
+      return new ResourceInstanceImpl(model) as T;
+    } catch (e: unknown) {


Following from https://github.com/rancher/dashboard/pull/17749/changes#r3311237610

the object used in create was

{ type: 'pod', spec: { template: {} } }

which is missing required stuff that our validation picks up. however the error message is orientated to form world "Name" is required.

for api use though we want the raw path in the error message not the human form name... alternatively we don't run validation and let the http error handle it

richard-cox · 2026-05-27T14:51:06Z

+    throw new Error(`ResourceInstance API error - ${ this._model?.type }/${ this._model?.id } - ${ message }`, { cause: e });
+  }
+
+  constructor(model: any) {


This process is a bit scary and generally with this stuff there's hidden dragons that only surface later in production.

I asked our dear friend gemini and they came up with some good catches

Object.getOwnPropertyDescriptors(model) only grabs the keys that exist at the exact moment of instantiation. If the underlying _model later receives a new property dynamically (e.g., a websocket update injects a new field that wasn't there initially), the ResourceInstanceImpl instance will not have a getter/setter for it and the property will be invisible to the consumer.

getOwnPropertyDescriptors only looks at the object's own properties. If the underlying model relies on getters or properties located on its prototype chain (which is common in class-based models like SteveModel), this constructor completely misses them.

Heavy Instantiation: Looping through every single key and calling Object.defineProperty is computationally expensive.

Memory Bloat: Inside the loop, get: () => this._model[key] creates a new anonymous closure function for every single property on every single instance.

i think we need to go down the worse but safest path of

aways return objects returned from dashboard actions without passing them through another class

when returning the object instance as it as the required interface

update SteveModel to implement the required interface (note though it's not TS)

though am open to other ideas, but basically we need to ensure we return the instance from the store

richard-cox · 2026-05-27T14:53:04Z

+      this.surfaceError('Cannot patch: permission denied');
+    }
+
+    const url = this._model.linkFor('update') || this._model.linkFor('self');


we should just be able to call save with additional args

richard-cox · 2026-05-27T14:53:57Z

        });

+        if (Array.isArray(response)) {
+          return response.map((r: any) => new ResourceInstanceImpl(r)) as FindFilteredPageResponse<T>;


we're de-references the collection. so any new / removed entries won't be applied to the response

same applies for the other map's

Co-authored-by: Richard Cox <18697775+richard-cox@users.noreply.github.com>

implement resources API part 2 + unit tests + demo interaction with p…

a81a86a

…ersistentvolume list view (to be deleted)

aalves08 added this to the v2.15.0 milestone May 20, 2026

aalves08 requested review from nwmac and richard-cox May 20, 2026 13:59

aalves08 self-assigned this May 20, 2026

aalves08 removed the request for review from nwmac May 20, 2026 14:02

aalves08 mentioned this pull request May 22, 2026

Resources api part 2 (WIP - resource instance API implementation proposal) #17389

Closed

9 tasks

aalves08 requested a review from nwmac May 27, 2026 14:44

richard-cox reviewed May 27, 2026

View reviewed changes

aalves08 and others added 3 commits May 27, 2026 18:33

Update shell/apis/intf/resources-api/resource-instance.ts

1a70786

Co-authored-by: Richard Cox <18697775+richard-cox@users.noreply.github.com>

Update shell/apis/intf/resources-api/resource-instance.ts

84e2061

Co-authored-by: Richard Cox <18697775+richard-cox@users.noreply.github.com>

Update shell/apis/resources/resource-instance-class.ts

5fd16c0

Co-authored-by: Richard Cox <18697775+richard-cox@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

implement resources API part 2#17749

implement resources API part 2#17749
aalves08 wants to merge 4 commits into
rancher:masterfrom
aalves08:resources-api-part-2.1

aalves08 commented May 20, 2026

Uh oh!

richard-cox left a comment

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026

Uh oh!

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026 •

edited

Loading

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026

Uh oh!

richard-cox May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

aalves08 commented May 20, 2026

Summary

Occurred changes and/or fixed issues

Technical notes summary

Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

Checklist

Uh oh!

richard-cox left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

richard-cox May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

richard-cox May 27, 2026 •

edited

Loading